Architecture
'Overview' We need to decide on a server model to build from. It should meet several criteria, not necessarily in order of priority: *The model should be highly scalable. Since the goal of the project is to introduce a text game into a large casual gaming population such as Facebook, the game should be prepared for a potential explosion in popularity, at least in short term players trying the game out. Ideally the game should be able to handle a large number (1000+) of players with little or no modification from its current player load abilities. *The model should be accessible, a number of different clients should be able to interact in a meaningful way with the game. *The model should be reliable. Uptime is a top priority **In the event of some kind of failure, the game should be up and running again quickly. **Some kind of redundancy might be ideal, in the event of hardware failures. **Updates to the server should be seemless to the end users *Quality of service should be comparable or better than the traditional client/server model of the current architecture. While the text nature of the game allows for some lag compared to other game types, the game should always feel near-instantly responsive. Players in locations not near the main server should be considered. *The model should be efficient **Memory **Processing time **Bandwidth **Develoepr Time **Financial Requirements *The model should be componetized to allow for clear distinctions between functionalities within the system **Authentication **Communication **Data Parsing **Content Delivery *The model should incorporate the end users into the process of improvement and refinement on the overall system stability **Content ***World ***Abilities ***Images ***Sounds ***Quests ***Stories **Logic **Behaviors *More criteria... Here we will discuss different modeling options, and the pros and cons of each. Please post diagrams or references where appropriate. 'Proxy Server Architecture' It has been generally agreed that since the logic used to connect clients to the mud is becoming increasingly complicated in order to incorporate both telnet and web client connections, a redesign is needed to simplify the structure. Additionally, incorporating an account system into the existing code would be a mess of another layer on the connection state. So, this design attempts to handle both problems with a simple system of proxy servers. The most simple configuration would include a game engine, a "world proxy" attached to an account interface, and separate proxy servers to handle telnet and web connections. Game Engine The game engine consists of the logic pertaining to a single game. It can do exactly two things: interpret user input, and update the game state in an infinite loop. Moving the client communication out of the game engine greatly simplifies its main loop. Incoming player input could theoretically then be treated as an event, rather than polling for new input in every loop iteration. For our initial purposes, however, we would simply break out the connection polling and replace it with a single data pipe to the world proxy. World Proxy Most of the time, this server acts as a bridge for one client between the telnet/web proxy and the game engine, merely passing the data through to its intended recipient. But, it has the added functionality of being an account interface, which intercepts an incoming connection and handles connecting to an account, logging in as a player on the game engine, and other account-related functions, such as updating your email address. Upon connecting to a game engine, the account interface is bypassed completely. This server connects to the game engine with a single pipe of data, and connects to web or telnet proxies with dedicated pipes. Telnet/Web Proxy These servers are similar in that they have a direct connection to a World proxy, but are tailored to efficiently send data to a single type of connection. The telnet proxy behaves much like the mud connection polling does now, simply looping over the connections and sending them messages. Future Use One of the big advantages of breaking the system into three distinct layers, is that it becomes easy to expand later as we gain more players and becomes difficult to handle on a single piece of hardware. There could easily be multiple game engines, each of which might be distributed. Each game engine could connect to multiple world proxies as needed to handle the connection load. Each world proxy could handle to as many client proxies as needed, although each client proxy would connect to only one world proxy. The scaling should be unlimited. 'Server Architecture' 'Client/Server Model' : This is the current model in use. : Pros: ::* Simple. A single game state, no complex synchronization between mirrors. ::* With modification by threading, processing can distributed among multiple cores/cpus. : Cons: ::*Quality of service dependent on latency and network distance from server. ::*Entire game state must fit on a single machine's memory and storage. ::*Even with threading, introduces some complexity from resource locking. ::*Number of players and quality of service are balanced by the limitations of a single piece of hardware. ::*Single point of failure. If the server goes down, all players are disconnected until rebooted/repaired. 'Mirrored Server' ' 'Driver Architecture Critical components include: *Modular design **Communication Manager **Storage Manager **Commands Manager **Abilities Manager **Quest Manager **Environment Manager **Logic Interpreter *Runtime modifiable *Interface Neutral